Transaction mediation method

ABSTRACT

Systems and methods for processing transactions using a digital payment platform.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. Nonprovisional ApplicationNo. 16/712,581 filed Dec. 12, 2019 which claims priority to U.S.Provisional Application No. 62/779,340 filed Dec. 13, 2018, all of whichare incorporated herein in their entireties by this reference.

TECHNICAL FIELD

This invention relates generally to the payments field, and morespecifically to a new and useful intermediary system for digital paymentprocessing in the payments field.

BACKGROUND

The rise of digital payment platforms has made it easier and cheaper forcustomers and merchants to complete transactions. However, these digitalpayment platforms evolved in a different ecosystem from conventionalpayment processing architectures (such as credit card systems), and havethus been unable to integrate with the conventional payment processingarchitectures, due to differences between the ecosystems' transactionflow, how funds are custodied, and stakeholder capabilities.

For example, conventional payment processing architectures settle toconventional merchant banks, while digital payment platforms directlysettle transactions between user and merchant accounts supported by thedigital payment platform. In another example, digital payment platformsinvert the traditional payment processing flow—instead of the merchantsending the user's payment information to the payment processor (as inconventional payment processing architectures), wherein the paymentprocessor processes the transaction, digital payment platforms requirethe user to send the transaction information to the digital paymentplatform, wherein the digital payment platform processes thetransaction.

These architectural and capability differences have precluded digitalpayment platforms from seamlessly integrating with conventional paymentprocessing architectures, which can be desirable to enable customers totransact with a wider range of merchants (e.g., merchants that have beenconnected to the conventional payment processing architectures, but notto the digital payment platforms), without requiring the merchants tochange their accounting or banking practices.

This invention provides such new and useful system and method to bridgethe digital payment platform into the conventional payment processingarchitectures.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 is a schematic representation of a method, in accordance withvariations.

FIG. 2 is a schematic representation of a system, in accordance withvariations.

FIG. 3 is a schematic representation of a system, in accordance withvariations.

FIG. 4 is a schematic representation of a system, in accordance withvariations.

FIG. 5 is a schematic representation of a method, in accordance withvariations.

FIG. 6 is a schematic representation of an example of merchantsettlement.

FIG. 7 is a schematic representation of a method, in accordance withvariations.

FIG. 8 is a schematic representation of a method, in accordance withvariations.

FIG. 9 is a schematic representation of a method, in accordance withvariations.

FIG. 10 is a schematic representation of a method, in accordance withvariations.

FIG. 11 is a schematic representation of a first example of a DPPrelationship with the acquirer and associated settlement method.

FIG. 12 is a schematic representation of a second example of a DPPrelationship with the acquirer and associated settlement method.

FIG. 13 is an example of the POS terminal reading the paymentinformation.

FIGS. 14A-D are illustrations of user interfaces, in accordance withvariations.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

The following description of the preferred embodiments of the inventionis not intended to limit the invention to these preferred embodiments,but rather to enable any person skilled in the art to make and use thisinvention.

1. Overview.

As shown in FIG. 1, the method includes one or more of: initiating atransaction request S100; determining whether a user has sufficientfunds for the transaction from a digital payment platform S200;generating a temporary payment card number S300; transmitting a paymentrequest to a payment network for processing S400; and functioning as anissuer for the payment network for transaction confirmation S500. Themethod can optionally include settling the merchant transactions S600.In some variations, the method is a method for mediating transactionsbetween digital payment platforms and conventional payment systems.

FIGS. 5 and 9 are schematic representations of a variation of themethod, in which the intermediary system 120 generates the temporarypayment card number and FIGS. 7 and 8 are schematic representations ofvariations of the method, in which the issuer system 710 generates thetemporary payment card number and functions as an issuer for thetemporary payment card number. FIG. 9 is a schematic representation of avariation of the method, in which the intermediary system 120 generatesthe temporary payment card number and the DPP 130 functions as an issuerfor the temporary payment card number.

In some variations, method functions to bridge the digital paymentplatform with conventional payment systems.

In an example of method use (specific examples shown in FIGS. 5 and 7),the user can have a digital wallet and/or account hosted by a digitalpayment platform (e.g., 130 shown in FIG. 3) (e.g., AliPay, etc.),wherein the digital wallet and/or account can be linked to a walletclient (e.g., wallet application) executing on the user device (e.g.,phone) (e.g., 150 shown in FIG. 3). When the user wants to pay for atransaction, the wallet client can present payment information (e.g., aQR code, NFC frame) (e.g., as shown in FIG. 13) that encodes the walletidentifier, the user account identifier, and/or other user identifierfor payment. The payment information is then read by a point of saleterminal (e.g., no shown in FIG. 3), which forwards the paymentinformation to the intermediary system (e.g., 120 shown in FIG. 3). Theintermediary system (e.g., 120) can: identify the digital paymentplatform (e.g., 130) associated with the payment information, determineuser- or account-identification information from the paymentinformation, and query the digital payment platform (e.g., 130 todetermine whether the user's wallet or account includes sufficient fundsor credit for the transaction.

When the digital payment platform indicates that the user has sufficientfunds and/or indicates that the intermediary system is authorized tocomplete the transaction (e.g., based on the metadata associated withpayment information presentation on the user device, which substantiallymatches the transaction data sent by the intermediary system with thequery), the intermediary system can generate a temporary credit cardnumber (and/or payment request, such as an ISO 8583 message) that iscompatible with the credit card network (e.g., VISA, MasterCard), andsend the temporary credit card number to the credit card network (e.g.,140 shown in FIG. 3) for standard processing (e.g., determine the issuerand send the payment request to the issuer via a determined acquirerand/or payment network). In specific examples, the temporary credit cardnumber can identify the intermediary system (e.g., 120) as the issuer,wherein the intermediary system returns a standard accept/deny responseto the payment network. In specific examples, the temporary credit cardnumber can be: valid for a limited period of time, be a single-use cardnumber, and be specific to the transaction, merchant, or othertransaction information, such that the temporary credit card numbercannot be used for another transaction.

When the intermediary system (e.g., 120) receives the forwarded paymentrequest from the credit card network (e.g., 140, the intermediary systemcan respond with an approval message, and can optionally evaluate thepayment request (e.g., based on a set of rules, such as whether themerchant is blacklisted or whitelisted, whether the payment informationfrom the payment request matches the payment information associated withthe temporary payment card number, whether the payment request isassociated with a live temporary payment card number or received withinan active time window associated with the temporary payment card number,whether the funding source (e.g., a customer's DPP account) for thetemporary payment card has been verified to have sufficient funds forthe transaction, etc.). The credit card network (e.g., 140) can thenforward the approval message to the point of sale terminal (e.g., 110)(e.g., directly, via the intermediary system; indirectly, using aconventional approve/deny response routing path; etc.) for messagedisplay to the user and the merchant. Alternatively, the intermediarysystem can forward the approval message to the merchant or POS terminalfor display.

In an example of settling the merchant transactions (example shown inFIG. 6), the merchant can send the settlement request to the credit cardnetwork (e.g., using conventional settlement methods, such as by usingthe POS system no), wherein the credit card network (e.g., 140) cansettle the transactions with the intermediary system (e.g., 120) as theissuer. In a first specific example, the intermediary system (e.g., 120)can pay the transaction amounts directly, from an account custodied bythe intermediary system. In some implementations, the intermediarysystem can receive funds from the user accounts hosted by the digitalpayment platform (e.g., during sufficient fund verification, at a latertime, during settlement, etc.). In a second specific example, theintermediary system (e.g., 120) can instruct the digital paymentsplatform (e.g., 130) to directly pay the credit card network or themerchant bank (e.g., 170 shown in FIG. 3) (e.g., wherein the merchantbanking information can be extracted from the settlement request). In athird specific example, the intermediary system (e.g., 120) can instructan issuer bank (e.g., 160 shown in FIG. 3) (custodying funds associatedwith the DPP and/or intermediary system) to pay the merchant bank(example shown in FIG. 7).

In some examples of settling the merchant transactions (example shown inFIG. 6), the merchant can send the settlement request to the credit cardnetwork (e.g., using conventional settlement methods) by using the POSsystem (e.g., 110), wherein the credit card network (e.g., 140) cansettle the transactions with an issuer system (e.g., 710 shown in FIG.7) as the issuer of the temporary payment card number. In some examples,the issuer system (e.g., 710 can instruct an issuer bank (e.g., 160shown in FIG. 3) to pay the merchant bank (example shown in FIG. 7).However, the transactions can be otherwise settled. However, the methodcan be otherwise performed.

2. Benefits

The intermediary system and method can confer several benefits overconventional payment systems.

Payment via a digital payment platform (DPP) typically involves transferof funds from a first account of the digital payment platform to asecond account of the digital payment platform, by the digital paymentplatform. Conventionally, for a merchant to accept payment via a digitalpayment platform, the merchant creates an account at the digital paymentplatform; thereafter, customers can pay the merchant by transferringfunds to the merchant's digital payment platform account.

Variations of systems and methods disclosed herein allow a customer topay a merchant by using a digital payment platform account in caseswhere the merchant does not have a digital payment platform account. Insome variations, an issuer account is created at the digital paymentplatform, wherein the digital payment platform can transfer funds from acustomer's DPP account (at the digital payment platform) to the issuer'sDPP account. In some variations, the issuer's DPP account is used as afunding source for a temporary payment card number. In some variations,a DPP account (e.g., a customer's DPP account) is used as a (direct orindirect) funding source for a temporary payment card number. In someimplementations, a transfer of funds (via the digital payment platform)from the customer's DPP account to the issuer's DPP account isassociated with a temporary payment card number.

First, the intermediary system (e.g., 120) enables the digital paymentplatform (e.g., 130) to interface with the conventional payment systemwithout partnering as an issuer with the conventional payment system. Inone variation, the intermediary system can function as the issuer inlieu of the digital payment platform. In a second variation, theintermediary system functions as an intermediary or manages fundtransfer and tracking between a conventional issuer and the digitalpayment platform.

Second, the intermediary system enables merchants who are outside of thedigital payment platform's ecosystem, but within the conventionalpayment system's ecosystem, to accept digital payments backed by thedigital payment platform. In some variations, during processing of apayment transaction using a customer's digital payment platform account,a temporary payment card number is generated (the funding source for thetemporary payment card number is the customer's DPP account), themerchant uses a payment network (e.g., a conventional credit cardnetwork) to charge the temporary payment card number for thetransaction's payment amount. In some variations, the funds for thecharge are provided by a bank account associated with the issuer's DPPaccount (or alternatively a bank account associated with the customer'sDPP account). In some variations, the funds for the charge are providedby a reserve bank account of the DPP. In some implementations, the bankaccount associated with the issuer's DPP account receives the funds forthe charge (or is replenished after the charge) from a bank accountassociated with the customer's DPP account. In this manner, a customercan initiate payment by using a digital payment platform account, andthe merchant receives funds as if the transaction was processed by usinga conventional payment system (e.g., a credit card network). Invariations, the merchant is not required to create an account at thedigital payment platform system, as long as an issuer account is createdto fund temporary payment card numbers.

Third, the intermediary system offers a more secure transaction methodby generating temporary and/or transaction-limited payment card numbers,which can preclude fraud if the temporary payment card number is stolen.The intermediary system and/or transaction mediation method can offerfurther security if the digital payment platform also uses temporarypayment information (e.g., QR codes, wallet identifiers, etc.), whichcan prevent fraud if the payment information is stolen (e.g., becausethe digital payment platform will reject a sufficient fund query basedon the stolen payment information).

Fourth, the method can allow merchants to keep their current point ofsale terminals (e.g., no new hardware needs to be purchased). Invariations, the intermediary system is simply added as a secondaryacquirer to the point of sale terminal, wherein transactions havingdigital payment information can be forwarded to the intermediary systeminstead of conventional acquirers. In variants, the point of saleterminal (e.g., 110) can make the initial determination on where toroute the payment request: the primary acquirer (e.g., conventionalacquirer) or the secondary acquirer (e.g., the intermediary system)based on the payment format and/or payment information.

However, the system and method can confer any other suitable set ofbenefits, including, but not limited to: providing a platform thataccepts visual identifier-based payments (e.g., QR code-based payments);supporting EMV rails for visual identifier payments; supporting DPPrails for visual identifier payments; driving down MDR fees formerchants; and supporting digital wallet applications.

3. System.

The intermediary system 120 functions to execute all or portions of themethod. In variants, the intermediary system 120 can be treated as, orperform all, or a portion of the functions of a conventional acquirer(e.g., to receive transaction requests from the merchant; to receive androute the payment information); a conventional processor (e.g., collectthe payment information, selectively routing the payment informationbased on whether the payment information is associated with a digitalpayment platform); as a conventional issuer (e.g., to settle merchanttransactions), example shown in FIG. 5; or as any other suitable creditcard processing entity. Additionally or alternatively, the intermediarysystem 120 can interact with conventional acquirers, processors, paymentnetworks, issuers (example shown in FIGS. 7 and 8), and/or any othersuitable entity. The intermediary system 120 preferably concurrentlyexecutes multiple instances of the method, but can alternatively executemultiple method instances serially. The intermediary system 120 ispreferably a remote computing system, but can alternatively be any othersuitable system. The intermediary system 120 is preferably separate anddistinct (e.g., owned by a separate entity) from the digital paymentplatform(s) 130 and/or the payment network(s) 140, but can alternativelybe hosted by the digital payment platform(s) and/or the paymentnetwork(s). An example of the intermediary system is the Poynt Cloud™.As shown in FIG. 2, in variants, the intermediary system 120 can be usedwith a point of sale terminal (POS terminal) no, a payment network (PN)140, a digital payment platform (DPP) 130, and/or any other suitable setof systems.

The intermediary system 120 can be associated with one or more digitalpayment platforms 130, which function to provide account management, P2Ptransfer, bill pay, digital ID storage, digital payments, online-checkout, as an issuer (example shown in FIG. 9), as an acquirer, and/orother services. Examples of digital payment platforms include AliPay,WeChat Pay, Venmo, Zelle, Airpay, Favepay, Remo, CC Financial Services,EZi Wallet, or any other suitable electronic payment platform ore-commerce payment platform. The digital payment platform 130 preferablymaintains one or more accounts for each user, wherein the accounts holdcustodied currency (e.g., fiat, cryptocurrency), be associated withcredit, or be associated with any other suitable form of payment.

The digital payment platform (DPP) 130 can be associated with one ormore wallets that function as a user interface between the user and thedigital payment platform. The wallet can be hosted by the digitalpayment platform 130, be a third-party wallet connected to the digitalpayment platform, or be any other suitable wallet. The wallet can:present payment information (e.g., associated with the user account onthe digital payment platform), receive payee information (e.g., read amerchant identifier to complete a transaction), initiate transactions orfund transfers, or perform any other suitable functionality. The walletis preferably a digital or electronic wallet executing on the userdevice 150, but can alternatively be a hardware key (e.g., an RFID orNFC tag with wallet information), or be otherwise configured. The walletpreferably runs (e.g., is executed by) on a user device, but can beotherwise implemented.

In one example of wallet operation, the wallet can generate or presentpayment information (e.g., in response to user instruction) for point ofsale terminal receipt. The payment information can include: a walletidentifier, a user account identifier, a user identifier, a card numberassociated with the digital payment system (e.g., a credit card number,a digital card number), a signed message (e.g., signed by the wallet oruser device's private key), or be any other suitable identifier. Thepayment information can be: temporary (e.g., for a limited time, for asingle transaction, for a limited number of transactions, etc.), static,or be otherwise limited or unlimited. The wallet can optionally store ortransmit the payment information to the digital payment platform 130(e.g., with or without payment information generation or presentationmetadata, such as payment information generation time, user devicelocation, etc.), wherein the digital payment platform 130 can store thepayment information (and any associated metadata) with the user account.However, the wallet can perform any suitable set of functionalities, andbe otherwise used.

In some variations, the intermediary system 120 is associated with apayment network (“rails”; PN) 140, which functions to: maintain one ormore transmission protocols, route payment requests to the issuersassociated with a payment card number, receive an approved or deniedmessage from the issuer, and relay the approved or denied message backto the acquirer (or intermediary system). The payment network 140 canoptionally facilitate transaction settlement, wherein the paymentnetwork receives one or more settlement requests from the merchant, eachwith one or more approved transactions, determines the issuers for eachof the transactions; requests money from the issuers; and distributesthe money to the merchants' bank 170. Examples of payment networksinclude American Express, Diners Club, JCB, Mastercard, UnionPay, Visa,and/or any other suitable payment network. Examples of banks include:Bank of China, DBS Bank, Oversea-Chinese Banking, The Association ofBanks in Singapore (PayNow), United Overseas Bank, Wells Fargo, Chase,Citibank, and/or any other suitable bank.

The intermediary system 120 can optionally interact with a conventionalacquirer (e.g., 720 shown in FIG. 7), which can function to receive androute the payment request (and/or transaction request). The acquirer 720is preferably an intermediary between the intermediary system 120 andthe PN 140 (e.g., receives the payment request from the intermediarysystem 130 and routes the payment request to the appropriate PN 140, butcan alternatively or additionally perform any suitable function. Theconventional acquirer 720 can be a bank (e.g., merchant bank, acquirerbank, issuer's bank, DPP's bank, intermediary system's bank, third partybank), or be any other suitable acquirer.

In some variations, the intermediary system 120 is associated with apoint of sale system 110 (e.g., point of sale terminal; POS terminal).The point of sale terminal no functions to obtain payment informationfrom a user. FIG. 14 illustrates an exemplary user interface displayedby the POS system 110 to prompt a user to provide their paymentinformation (e.g., by scanning a QR code using a camera or scanner ofthe POS system 110). The point of sale terminal no can receive thepayment information by: reading a visual code encoding the paymentinformation (e.g., scanned off of a user device executing a walletapplication or other digital payment application); receiving data from ashort-range wireless communication system, such as an NFC payment systemor RFID payment system; reading the payment information off of a paymentcard (e.g., a magstripe, an integrated circuit chip, etc.), or otherwisereceiving the payment information. The point of sale terminal no canoptionally determine (e.g., receive, generate) transaction information(e.g., the transaction amount, purchased items, transaction time,transaction geolocation, etc.); determine a merchant identifier (e.g.,the POS terminal identifier, the intermediary system's merchantidentifier, the merchant bank's merchant identifier, a global merchantidentifier, etc.); determine how to route payment information or paymentrequests (e.g., example shown in FIG. 3); or determine any othersuitable information.

The intermediary system 120 can be used with an acquirer system (e.g.,720) that functions to receive payment information. The acquirer system720 can optionally function to determine how to route paymentinformation or payment requests (e.g., to the intermediary system, tothe PN, etc.), example shown in FIG. 4. The acquirer system can be: thePOS terminal, a merchant bank, or any other suitable acquirer system.

4. Method.

As shown in FIG. 1, the method includes at least one of: initiating atransaction request S100; determining whether a user has sufficientfunds for the transaction from the digital payment platform S200;generating a temporary payment card number S300; transmitting a paymentrequest to a payment network for processing S400; and functioning as anissuer for the payment network for transaction confirmation S500. Themethod can optionally include settling the merchant transactions. Thetransaction mediation method functions to integrate digital payments,supported by digital payment platforms, into conventional paymentprocessing architectures.

In some variations, at least one of the POS terminal, the intermediarysystem, the digital payment platform, the payment network, an issuersystem, an acquirer system, and/or any other suitable system can performat least a portion of the method.

In some variations, the method is performed by an intermediary system,but can additionally or alternatively be performed by the paymentnetwork, the digital payment platform, or by any other suitable entity.

The method is preferably performed each time a digital payment is made,but can alternatively or additionally be performed each time a digitalpayment is made with a merchant outside of the digital payment platform(e.g., a merchant without a digital payment platform account oridentifier), or at any suitable time.

When information or data is stored or transferred, the information ordata can be: cleartext, as a hash, in an encrypted format (e.g.,encrypted with a key associated with the intermediary system, the DPP,the payment network, the issuer, etc.), signed (e.g., with averification key associated with the merchant, the intermediary system,the DPP, etc.), and/or otherwise stored.

Initiating a transaction request S100 functions to initiate thetransaction mediation process. The transaction request is preferablyinitiated by the POS system, but can alternatively be initiated by theintermediary system 120, by the PN 140, by the DPP 130, or by any othersuitable system.

The transaction request can include: the payment information, thetransaction amount, a merchant identifier, other transaction information(e.g., transaction time), or any other suitable information. Invariants, the transaction request can be a payment message (e.g., an ISO8583 message).

The intermediary system preferably stores all or a portion of the datawithin the transaction message (e.g., for payment verification in S500),but can process the transaction request in any suitable manner. In oneexample, the intermediary system stores the transaction information(e.g., transaction amount, transaction timestamp) and the merchantidentifier for payment verification in S500.

The transaction request is preferably generated in response to receivingthe payment information from the user, but can be generated at anysuitable time. Receiving the payment information from the user caninclude: scanning, reading, receiving a frame, or otherwise receivingpayment information from a payment storage mechanism (e.g., a digitalwallet, a physical card, etc.).

The payment information can be provided to the POS terminal 110 in theform of: a visual identifier (e.g., QR code, barcode, text, etc.)displayed on a user device 150, a short-range wireless communicationframe (e.g., NFC frame, RFID frame), a physical card (e.g., magstripe orIC chip), manually entered, or in any other suitable format.

The payment information can be: static (e.g., a static value),dynamically determined and transaction- or time-limited (e.g., randomlygenerated for the transaction, calculated using the payment informationpresentation timestamp, generated using a security key, etc.), or haveany suitable set of properties. When the payment information is dynamic,the payment information is preferably generated by the DPP (e.g., basedon the timestamp, the user account, the transaction information, etc.),but can be generated by any other suitable system. When the paymentinformation is dynamic, the digital payment platform 130 preferablystores the presented payment information in association with therespective DPP user account for later payment validation.

The payment information can include: a user account identifier (e.g.,globally unique, temporally unique, static, dynamically generated by theDPP and provided to the user, etc.), a DPP identifier, and/or any othersuitable information.

S100 (initiating a transaction request) preferably includes: generatingthe transaction request and providing the transaction request to theintermediary system 120. However, S100 can be otherwise performed.

Generating the transaction request can include: receiving the paymentinformation (e.g., from the user), receiving the transaction information(e.g., from the merchant, from POS system memory, etc.), and generatingthe transaction request based on the payment information and thetransaction information. Generating the transaction request canoptionally include encrypting the transaction request.

The transaction request is preferably generated (and provided) by thePOS system, but can additionally or alternatively be generated by awebsite, a server, or any other suitable system. Thetransaction-generating system preferably generates the transactionrequest in response to receiving the payment information from the user,but can alternatively be generated at any suitable time.

The system generating the transaction (e.g., the POS system 110) canreceive the payment information via at least one of: a user input deviceof the POS system, a camera of the POS system, a scanner of the POSsystem, a wireless communication system of the POS system, a user device(e.g., 150), a card reader, and/or any other suitable device. In oneexample, receiving payment information includes scanning a QR codedisplayed by a user device (e.g., 150) by using a camera of the POSsystem no. However, the transaction request can be otherwise generated.

Providing the transaction request to the intermediary system 120functions to send the transaction request to the intermediary system.The transaction request can be: transmitted, broadcast, pulled (e.g.,requested by the intermediary system), or otherwise provided to thetransaction request. The intermediary system preferably receives thetransaction request (e.g., from the transaction request generatingsystem, from a transmitting system, from a payment network, etc.), butcan alternatively generate the transaction request or otherwise obtainthe transaction request.

In some variations, providing the transaction request can optionallyinclude: determining whether the payment information corresponds to apayment network or a DPP. This can be used to: generate the transactionrequest, route the transaction request, or otherwise used. This can beperformed by the transaction request generating system (e.g., the POSsystem), the intermediary system, and/or any other suitable system.

In a first embodiment, the POS system determines whether the paymentinformation corresponds to a payment network or a DPP, and optionally,which payment network or DPP. In one example, the transaction request isgenerated according to the associated payment network's standard whenthe payment information is associated with a payment network, andgenerated according to the intermediary system's or DPP's standards whenthe payment information is associated with a DPP. In a second example,the transaction request can be sent to the associated payment network(e.g., associated with the merchant) when the payment information isassociated with the payment network, and sent to the intermediary systemwhen the payment information is associated with a DPP. However, thetransaction requests can be otherwise generated or sent. In somevariations, the POS system 110 provides the transaction request to theintermediary system 120 responsive to a determination that the paymentinformation corresponds to a DPP.

In a second embodiment, the intermediary system determines whether thepayment information corresponds to a payment network or a DPP, andoptionally, which payment network or DPP. In this embodiment, thetransaction request is preferably in a standard format, and theintermediary system can selectively route or process the transactionrequest in accordance with the disclosed method, depending on whetherthe payment information was associated with a payment network or a DPP,respectively. In some examples, the intermediary system 110 receives thepayment information from the POS system 110, and determines whether thepayment information corresponds to a DPP.

However, S100 can be otherwise performed.

FIGS. 14A-C illustrate user interfaces displayed on a customer-facingdisplay 111 and a merchant-facing display 112 of the POS system 110. Insome implementations, S110 includes the POS system 110 displaying a userinterface (e.g., as shown in FIG. 14B) on a customer-facing display(e.g., 111 shown in FIG. 13) promoting a user to scan a QR code, and thePOS system scanning the customer's QR code (e.g., as shown in FIGS. 14Cand 14D).

In some variations, the transaction request is routed to theintermediary system 120 for receipt, but can be otherwise initiatedand/or received by the intermediary system.

In a first example, the POS terminal no directly sends the paymentinformation (e.g., in the transaction request) to the intermediarysystem 120, wherein the intermediary system 120 can selectively initiatethe remainder of the method (e.g., when the payment information isassociated with a DPP) or route the transaction request (in the form ofa payment request) to a conventional acquirer (e.g. 720).

In a second example, a transaction routing system can: receive thepayment information; determine the payment type (e.g., conventionalpayment or digital payment); determine an endpoint based on the paymenttype (e.g., conventional acquirer, e.g., 720, for conventional paymentsor intermediary system 120 for digital payments); generate a paymentmessage or transaction request including the payment information,transaction information, and/or any other suitable information; andtransmit the payment message to the determined endpoint. In thisvariation, the intermediary system 120 receives the transaction requestwhen the determined endpoint is the intermediary system 120. However,the payment information can be otherwise routed.

The payment type can be determined based on: the mechanism used toobtain the payment information (e.g., wherein payment information readby optical scanners and short-range communication can be considereddigital payments, and payment information read by magstripe readers orIC chip readers can be considered conventional payments), the paymentinformation itself (e.g., based on the payment information format,length, numbers, etc.), based on an entry received from the user ormerchant (e.g., wherein the user or merchant selects a DPP as a paymentoption on the POS terminal), or otherwise determined.

The transaction routing system can be: the intermediary system 120, thePOS terminal 110 (e.g. wherein the POS terminal directly routes thetransaction request to the intermediary system 120 upon determinationthat the payment information is associated with a digital payment), anacquirer (e.g., 720) (e.g., a conventional acquirer, wherein theintermediary system 120 can be registered as an auxiliary paymentnetwork for payment information associated with a digital payment), orbe any other suitable system. However, the transaction request can berouted in any other suitable manner.

Determining whether a user has sufficient funds for the transaction fromthe digital payment platform S200 functions to determine whether thedigital payment platform 130 will fulfill the transaction. In somevariations, S200 is performed responsive to a determination that thepayment information corresponds to a DPP. In some variations, S200includes determining whether a DPP user account associated with thepayment information has sufficient funds for the transaction request. Insome variations, determining whether a DPP user account associated withthe payment information has sufficient funds for the transaction requestincludes identifying a DPP associated with the DPP user account, andcommunicating with the DPP.

S200 is preferably performed by the intermediary system 120, but canalternatively be performed by the merchant bank (e.g., 170), the PN 140,the POS terminal 110, or by any other suitable entity. S200 ispreferably performed after receipt of the transaction request S100(e.g., at the intermediary system), but can alternatively oradditionally be performed: upon receipt of the payment information, uponreceipt of the payment message from the PN in S500 (e.g., wherein the PNtreats the DPP as an issuer), or at any suitable time.

In a first variation, S200 includes: extracting the payment informationfrom the transaction request; optionally determining a DPP (e.g., 130)based on the payment information; and querying the DPP 130 based on thepayment information (e.g., via an API provided by the DPP). In a secondvariation, S200 includes: extracting the payment information and thetransaction amount from the transaction request; identifying a useraccount associated with the payment information; and determining whetherthe user balance (e.g., currency, available credit, etc.) exceeds thetransaction amount by a predetermined amount. However, S200 can beotherwise performed.

Determining a temporary payment card number S300 functions to generate acard number that is compatible with the payment network(s) 140.

The temporary payment card number can be generated: by the intermediarysystem 120 (example shown in FIG. 5 and FIG. 9), by a third party (e.g.,an issuer system, example shown in FIG. 9; a third party card generationsystem; etc.), by the DPP, and/or by any other suitable system. When thetemporary payment card number is generated by a third party system, S300can include sending a card generation request to the card generationsystem, wherein the card generation request can include: a request for anew card number, validity parameters (e.g., validity duration, validitygeolocation), a payment network (e.g., selected based on the acquirerassociated with the merchant, based on the merchant, etc.), transactionparameters (e.g., transaction amount, merchant identifier, etc.), anissuer identifier (e.g., the intermediary system, the DPP, an issuerbank, etc.), and/or any other suitable set of request parameters.Validity parameters can be: predetermined, automatically determined(e.g., based on user habits, based on the payment network, etc.),manually specified, or otherwise determined. The request parameters canoptionally be stored in association with the temporary payment cardnumber by the intermediary system 120 or by any other suitable system.

The temporary payment card number can be generated: in response toreceipt of the transaction request; after determination that the userhas sufficient funds for the transaction (e.g., in response to receiptof an authorization confirmation for the transaction from the DPP);before receipt of the transaction request (e.g., wherein a set or batchof temporary payment card numbers are generated and unassigned;generated for each user; etc.); or generated at any other suitable time.When the temporary payment card numbers are pre-generated, a temporarypayment card number can be activated (e.g. for the validity duration)for a user in response to receipt of the transaction request S100,sufficient fund determination S200, or at any other suitable time.

In some variations, S300 includes generating a temporary payment cardnumber that uses the DPP as a funding source. In some variations, S300includes storing a data structure that identifies the DPP as a fundingsource for the temporary payment card number. In some variations, S300includes the intermediary system 120 sending a card number generationrequest to an issuer system (e.g., 710).

S300 can optionally provide level of security to the digitaltransaction, in case payment information is stolen. S300 is preferablyperformed by the intermediary system 120, but can alternatively beperformed by the merchant bank 170, the PN 140, the POS terminal 110,the DPP 130 (e.g., wherein the DPP returns the temporary payment cardnumber), an issuer system 710, or by any other suitable entity. S300 ispreferably performed after receiving confirmation of user fundavailability from the DPP 130 (e.g., at the intermediary system 120),but can alternatively or additionally be performed: upon receipt of thepayment information, upon receipt of the transaction request (e.g., inparallel or asynchronously with S200), or at any suitable time.

The temporary payment card number is preferably temporarily valid for avalidity duration (e.g., active time window), which can increase paymentsecurity because the temporary payment card number will not be approvedby the intermediary system outside of the validity duration. Thevalidity duration can be: a static duration (e.g., 4 seconds), be theamount of time for a PN to verify the transaction with an issuer, bemanually set, or be otherwise determined. The temporary payment cardnumber is preferably authorized for only the transaction amount, but canalternatively be authorized for: a predetermined amount above thetransaction amount, a predetermined amount (e.g., for the user), thecredit limit or account limit of the user's DPP account, or any othersuitable amount.

The temporary payment card number can be persisted or stored for: thevalidity duration, until the associated transaction is settled, or forany suitable period of time. The temporary payment card number canoptionally be stored with: the transaction information, the merchant,the payment information, the DPP, an issuer (e.g., associated with theDPP, the card number generator, etc.), the payment network (e.g., Visa,Mastercard, etc.), a validity time or duration, and/or any othersuitable information. The temporary payment card number and optionallyany associated information, such as the issuer or the payment network,can optionally be transmitted to the DPP, the issuer, and/or any othersuitable system (e.g., for subsequent transaction settlement).

The temporary payment card number is preferably unique within theintermediary system, such that each temporary payment card number mapsto a single transaction, but can alternatively be unique to a user, awallet, a user account on the digital platform, or be otherwise mapped.The temporary payment card number is preferably globally unique within apredetermined timeframe (e.g., for a multiple of the validity duration,for an hour, for a day, for a week, etc.), wherein the temporary paymentcard number can be reused after the predetermined timeframe, but canalternatively be unique for all time (e.g., never reused).

The temporary payment card number can be stored in association with thetransaction request (e.g., merchant identifier, transaction information,etc.), such that a subsequent payment message (including the temporarypayment card number and/or transaction-associated information) can beverified against the information stored in association with thetemporary payment card number. This can function to restrict temporarypayment card number use to the merchant or transaction identified in thetransaction request. Alternatively or additionally, the temporarypayment card number can be transmitted to the DPP 130 (e.g., wherein theDPP can function as the issuer), or be otherwise managed or used.

The temporary payment card number is preferably compliant withconventional payment card standards (e.g., ISO/IEC 7812-1:1993, ANSIX4.13), but can alternatively have any suitable format. Examples of thetemporary payment card number can be a credit card number, a smart cardnumber, a debit card number, or be any other suitable card number.

In one example, the temporary payment card number can include a seriesof numbers, wherein the series can include: a Major Industry Identifier(MII), a Issuer Identification Number (IIN) or Bank IdentificationNumber (BIN), an individual account number, and a checksum.

In a specific example, the MII in the temporary payment card number canbe the MII associated with a PN 140 used by the intermediary system(e.g., the PN partnered with the intermediary system; a PN selected bythe intermediary system based on fee, speed, or other optimization;etc.), or be otherwise determined.

In a specific example, the TIN or BIN in the temporary payment cardnumber can be a number associated with the intermediary system 120 or anissuer system 710 (e.g., conventional bank, a card issuer platformexposing a card issuance API, etc.) associated with the intermediarysystem 120 (e.g., wherein the intermediary system can facilitate fundtransfer from the DPP to the conventional issuer as part of S200;wherein the DPP has funds deposited with the conventional issuer tocover user transactions; etc.), or be any other suitable IIN or BIN.

In a specific example, the individual account number in the temporarypayment card number can be the temporary portion of the temporarypayment card number. The individual account number is preferablyassociated with the transaction request (e.g., with the merchantidentifier, the transaction information, etc.), but can alternatively oradditionally be associated with the payment information, unrelated tothe transaction request, or otherwise associated with the transaction.The individual account number can be randomly generated, generated basedon the transaction information (e.g., based on the transaction amount,the transaction time, the merchant identifier, etc.), be a rotatingnumber that is temporarily assigned to the transaction request, begenerated based on a set of rules, be requested from a third-partycredit card number provider, or otherwise determined.

However, the temporary payment card number can be otherwise generated.

Transmitting a payment request to a payment network for processing S400functions to interface with conventional payment processingarchitectures (e.g., 140) (e.g., to process the digital paymentinformation as if it were a credit card).

All or portions of S400 are preferably performed by the intermediarysystem 120, but can alternatively be performed by the merchant bank 170,the POS terminal 110, the DPP 130, the acquirer 720, or by any othersuitable entity. S400 is preferably performed after S300, but canalternatively be performed at any suitable time.

In some variations, the payment request is a request for requestingpayment from the temporary payment card number to a merchant accountassociated with the transaction request, for a transaction amountidentified by the transaction request.

S400 can include: generating a payment request; optionally selecting aPN 140; and transmitting the payment request to the PN (e.g., directlyor via a conventional acquirer). In variants where a PN is selected, theMII associated with the PN is preferably included in the temporarypayment card number; alternatively, a different MII can be used. Thepayment request preferably includes the temporary payment card number(generated in S300), but can alternatively include the paymentinformation received from the user, or any other suitable information.The payment request can optionally include: transaction information(e.g., extracted from the transaction request); a merchant identifier(e.g., extracted from the transaction request or determined from the POSterminal transmitting the transaction request); or any other suitableinformation. In a specific example, the payment request can be an ISO8583 message.

In a first variation, the IIN identifies the intermediary system 120 asthe issuer. In operation, the PN 140 receives the payment request;identifies the intermediary system 120 as the issuer from the temporarypayment card number within the payment request; and routes the paymentmessage back to the intermediary system 120 for acceptance or denial.

In a second variation, the IIN identifies the DPP 130 as the issuer,wherein the intermediary system 120 (or other temporary payment cardnumber provider) can transmit the temporary payment card number and anytransaction-identifying information to the DPP prior to S500. Inoperation, the PN 140 receives the payment request; identifies the DPP130 as the issuer from the temporary payment card number within thepayment request; and routes the payment message to the DPP 130 foracceptance or denial.

In a third variation, the IIN identifies a conventional bank associatedwith the DPP or intermediary system as the issuer, wherein theintermediary system 120 (or other temporary payment card numberprovider) can include the bank's IIN or BIN and/or the DPP orintermediary system's bank account number when generating the temporarypayment card number in S300. In operation, the PN 140 receives thepayment request; identifies the bank as the issuer from the temporarypayment card number within the payment request; and routes the paymentmessage to the bank for acceptance or denial. In this variation, thetransaction-identifying information and/or payment message transmissiontime can be used to map the payment request to the transaction.

In a fourth variation, the IIN identifies an issuer system (e.g., 710)that provides an API (Application Programming Interface) for generatingtemporary payment card numbers as the issuer. In operation, the PN 140receives the payment request; identifies the issuer system (e.g., 710 asthe issuer from the temporary payment card number within the paymentrequest; and routes the payment message to the issuer system (e.g., 710for acceptance or denial. However, S400 can be otherwise performed.

The method can optionally include functioning as an issuer for thepayment network for transaction confirmation S500 functions to returnmessages compliant with the payment network's protocol. All or portionsof S500 are preferably performed by the intermediary system 120, but canalternatively be performed by the issuer bank (e.g., bank associatedwith the intermediary system or the DPP, a third-party issuer bank,etc.), the DPP, an issuer system (e.g., 710 or by any other suitableentity. S500 is preferably performed after receiving the payment messagereceived from the PN (e.g., after S400), but can alternatively beperformed after S200 or at any suitable time.

S500 can include: receiving the payment message from the PN 140;verifying the payment message in response to payment message receipt;and transmitting an approved response to the PN when the payment messageis verified, and transmitting a denied response to the PN when thepayment message is not verified. The approved response or deniedresponse is preferably returned to the PN, wherein the PN relays theresponse back to the POS terminal 110 for display. Alternatively, theintermediary system 120 can directly send the response to the POSterminal 110, wherein the response relayed from the PN can be ignored orotherwise managed. However, S500 can include any other suitable set ofprocesses.

Verifying the payment message functions to confirm that the paymentmessage is for the authorized transaction, and not for an unauthorizedtransaction. In some variations, verifying the payment message includes:extracting the temporary payment card number from the payment message;and determining that the temporary payment card number has not expired.In some variations, verifying the payment message includes: extractingtransaction-identifying information from the payment message (e.g.,transaction amount, merchant identifier); determining the authorizedtransaction-identifying information stored in association with thetemporary payment card number; and verifying the payment message whenthe payment message's transaction-identifying information and the storedtransaction-identifying information match. In some variations, verifyingthe payment message includes: confirming that the payment messagecorresponds to a temporary payment card number managed by theintermediary system, and optionally confirming that the funding sourcefor the temporary payment card number of the payment message hassufficient funds for the payment request. In some variations, the systemverifying the payment message (e.g., the intermediary system 120, anissuer system 710) stores information (e.g., accessed during S200)indicating that a funding source for the temporary payment card numberincluded in the payment request has sufficient funds for the paymentamount identified by the payment request. In some variations, the systemverifying the payment message (e.g., the intermediary system 120, anissuer system 710) stores information (e.g., accessed during S200)identifying the funding source, and the system verifying the paymentmessages queries the funding source to determine whether funding sourcehas sufficient funds for the payment amount identified by the paymentrequest. In some variations, the funding source is a user's DPP accountthat is associated with the transaction request of S100. In somevariations, the system verifying the payment message (e.g., theintermediary system 120, an issuer system 710) stores information (e.g.,accessed during S200) identifying each temporary payment card numberissued by the system verifying the payment message (and optionallyidentifying at least one of a funding source for the payment card numberand an authorized payment amount).

In some variations, verifying the payment message includes: confirmingthat the payment message identifies a transaction amount identified bythe transaction request, confirming that the payment message identifiesa merchant identified by the transaction request, and optionallyconfirming that the funding source for the temporary payment card numberof the payment message has sufficient funds for the payment request.However, the payment message can be otherwise verified (e.g., accordingto a set of rules, etc.).

The method can optionally include settling the merchant transactionsS600, which functions to transfer funds for the transaction into amerchant's account (e.g., via Interchange), example shown in FIG. 6.

In some variations, all or portions of S600 is performed by the PN 140.In some variations, at least a portion of S600 is performed by at leastone of the intermediary system 120, the merchant bank 160, the issuersystem 710, the DPP 130, the Payment Network 140, and the issuer bank160, and/or any other suitable system. S600 can be initiated (e.g.,requested) by: the merchant, the POS system 110, the acquirer system720, the intermediary system 120, and/or any other suitable system.

In some variations, S600 includes the POS system 110 initiating asettlement request (e.g., on a predetermined schedule, in response toreceipt of a user settlement request). In some variations, S600 includesthe POS system 110 requesting the payment network 140 to send thesettlement request to the system functioning as the issuer for thetemporary payment card number (e.g., the intermediary system 120, theissuer system 710, etc.). In some variations, S600 includes the acquirersystem 720 initiating a settlement request (e.g., on a predeterminedschedule).

In some variations, S600 includes the payment network 140 receiving thesettlement request. In some variations, S600 includes the paymentnetwork 140 forwarding the settlement request to the intermediary system120, and the intermediary system 120 initiating transfer of funds to themerchant bank 170. In some implementations, initiating transfer of fundsincludes the intermediary system 120 sending a request to the DPP 130 totransfer funds (used to fund the temporary payment card number) to themerchant bank 170. In some implementations, initiating transfer of fundsincludes the intermediary system 120 sending a request to the DPP 130 totransfer funds (used to fund the temporary payment card number) to theintermediary system 120 (or alternatively an issuer bank 160 associatedwith the intermediary system 120); in response to receiving the fundsfrom the DPP 130, the intermediary system 120 transfers the funds to themerchant bank 170. Alternatively, the intermediary system 120 transfersthe funds to the merchant bank 170 before receiving the funds from theDPP 130.

In some variations, S600 includes the payment network forwarding thesettlement request to the issuer system 710, and the issuer system 710initiating transfer of funds to the merchant bank 170. In someimplementations, initiating transfer of funds includes the issuer system710 sending a request to the DPP 130 to transfer funds (used to fund thetemporary payment card number) to the merchant bank 170. In someimplementations, initiating transfer of funds includes the issuer system710 sending a request to the DPP 130 to transfer funds (used to fund thetemporary payment card number) to the issuer system 710 (oralternatively an issuer bank 160 associated with the issuer system 710);in response to receiving the funds from the DPP 130, the issuer system710 transfers the funds to the merchant bank 170. Alternatively, theissuer system 710 transfers the funds to the merchant bank 170 beforereceiving the funds from the DPP 130.

S600 can be performed in real time, asynchronously, or at any othersuitable temporal relationship to: S600 initiation, transactionconfirmation, and/or another suitable event.

In some variations, S600 is performed in response to an approvalresponse transmission in S500, (e.g., upon payment message approval). Insome variations, S600 is performed in response to receipt of asettlement request from the PN 140 or merchant bank 170 (e.g., whereinthe intermediary system 120 can send a request to the DPP 140 totransfer the funds from the respective user account to the merchant bank170). In some variations, S600 is performed in response to user fundconfirmation in S200. In some variations, S600 is performed in responseto receipt of a merchant request. In some variations, S600 is performedat a predetermined frequency (e.g., at the end of the day, at 6 p,weekly, etc.). However, S600 can be performed at any suitable time.

The merchant account is preferably maintained by a conventional bank(e.g., merchant bank 170), but can alternatively be maintained by theDPP 140, the intermediary system 120, or by any other suitable system.

In one variation, S600 includes: receiving a settlement requestincluding a transaction identifier (e.g., transaction amount, etc.) anda merchant account identifier from the PN 140; and initiating fundtransfer to the merchant account (or other merchant deposit endpoint).The settlement request (e.g., reconciliation file, report, settlementfile) can be received from the PN 140: after settlement request receiptat the PN 140 from a merchant (e.g., an individual settlement request, abatch of settlement requests, etc.); after downloading thereconciliation files from the PN 140; or at any suitable time.

Initiating fund transfer can include: transmitting a fund transferrequest to the DPP 130, wherein the fund transfer request can include:the transaction identifier (or user account identifier associated withthe transaction identifier) and the merchant account identifier (orother merchant deposit endpoint); transferring the funds from the DPPaccount to the merchant account; or otherwise initiating fund transfer.

In one example, the merchant systems can directly integrate with the DPP130 (example shown in FIG. 10). In this example, the intermediary system120 transmits a payment request directly to the DPP 130, and the DPP 130settles the merchant transaction with the merchant bank 170.

In a second example, a payment agreement is established between the DPP130 and the acquirer 720, and the acquirer establishes a correspondingpayment agreement with the merchant (example shown in FIG. 11).

In a third example, a payment agreement is established between the DPP130 and the merchant (example shown in FIG. 12). However, any suitableentity can function as the issuing bank, and funds can be transferred onthe DPP or DDP user's behalf to the acquirer in any suitable manner.

An alternative embodiments of the above can be implemented in acomputer-readable medium storing computer-readable instructions. Thecomputer-readable medium may be stored on any suitable computer readablemedia such as RAMs, ROMs, flash memory, EEPROMs, optical devices (CD orDVD), hard drives, floppy drives, or any suitable device. Thecomputer-executable component is preferably a processor but theinstructions may alternatively or additionally be executed by anysuitable dedicated hardware device

Embodiments of the system and/or method can include every combinationand permutation of the various system components and the various methodprocesses, wherein one or more instances of the method and/or processesdescribed herein can be performed asynchronously (e.g., sequentially),concurrently (e.g., in parallel), or in any other suitable order byand/or using one or more instances of the systems, elements, and/orentities described herein.

As a person skilled in the art will recognize from the previous detaileddescription and from the figures and claims, modifications and changescan be made to the preferred embodiments of the invention withoutdeparting from the scope of this invention defined in the followingclaims.

We claim:
 1. A method comprising: with an intermediary system:determining whether a DPP (digital payment platform) user accountassociated with payment information has sufficient funds for atransaction request; responsive to a determination that the DPP useraccount has sufficient funds for the transaction request, generating atemporary payment card number that uses the DPP as a funding source; andtransmitting a payment network payment request to a payment network,wherein the payment request is a request for requesting payment from thetemporary payment card number to a merchant account associated with thetransaction request, for a transaction amount identified by thetransaction request.